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Introduction 
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The  most  well~known  program  verification  technique  is  based 
upon  the  Floyd-Naur  idea  of  inductive  assertions  [4] :  A  programming 
language  command  inposes  certain  fixed  implications  between  the 
relations  holding  among  the  values  of  program  variables  just  before 
and  just  after  the  execution  of  that  command.  The  (partial)  cor¬ 
rectness  of  a  program  can  thus  be  proved  if  the  output  specification 
claimed  at  the  program  exit  are  derived  from  the  input  specifications 
assumed  at  the  entrance  by  following  the  chain  of  implications 
mentioned  above  for  all  en trance- to-exit  control  flow  paths  in 
the  program.  Usually,  this  requires  1)  the  invention  of  a  number 
of  assertions  associated  with  some  key  points  ("outpoints")  in 
the  program  2)  the  generation  of  the  implications  mentioned  above 
("verification  conditions")  for  every  pair  of  adjacent  points 
chosen,  cuid  3)  the  demonstration  (possibly,  using  the  services 
of  a  theorent-prover)  that  each  of  these  implications  is  true. 

Of  these,  the  second  task  —  the  generation  of  verification  condi¬ 
tions  is  strictly  a  mechanical  process  requiring  substitution  and 
simple  arithmetical  evaluation.  The  lambda- calculus  has  built-in 
rules  to  carry  out  the  process  of  sxjbstitution  and  can  be  easily 
augmented  with  arithmetical  evaluation  rules.  Thus,  it  seems 
reasonable  to  seek  a  Icimbda-calculus-based  method  for  the  automatic 
generation  of  verification  conditions. 

In  this  paper  we  develop  such  a  method.  It  has  been  obtained 
by  extending  an  existing  [1]  leimbda-calculus  model  of  progremnming 
languages  in  which  programs  are  translated  into  lambda-expressions 
such  that  the  (numerical)  execution  of  progr2uns  is  modelled  by  the 
lambda-calculus  process  of  reduction.  In  the  new  model,  a  program 
is  effectively  translated  into  a  lambda-expression  whose  reduction 
yields  a  list  of  all  verification  conditions.  The  extension  from 
the  previous  to  the  new  model  is  non-trivial,  for  we  are  now 
interested  in  a  sense  in  the  symbolic,  rather  than  numerical, 
evaluation  of  programs. 

For  generating  verification  conditions,  one  must  have  a 
program  as  well  as  inductive  assertions  associated  with  certain 


properly  chosen  outpoints  in  the  program.  We  specify  a  programming 
language  in  which  inductive  assertions  are  incorporated  within 
the  program  body  by  means  of  specie^,  assert  statements.  Equipped 
with  assignments/  conditionals/  compounds,  ALGOL-type  blocks, 
and  loops,  this  language  is  simple  yet  quite  powerful.  We  then 
present  a  set  of  translation  rules  mapping  the  statements  of 
the  specified  programming  language  into  lambda-expressions. 

Using  these  rules,  a  program  can  be  effectively  translated  into 
a  lambda-expression,  say  by  extending  the  compiler  of  [5]. 

Finally,  we  show  that  the  model  is  correct  in  the  sense  that 
the  treuislation  of  any  program  produced  by  our  rules  does  indeed 
give  all  verification  conditions. 
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Verification  Conditions 

Given  a  program,  in  the  flowchart  form,  say,  and  the  program 
input  and  output  conditions,  the  inductive  assertion  method  to 
prove  the  peurtial  correctness  of  the  program  proceeds  as  follows 
Cl4],  explanation  in  [?]).  First,  outpoints  are  chosen  on  the 
flowchart  edges  such  that  there  is  at  least  one  outpoint  in  each 
loop*  Outpoints  are  also  placed  on  the  start  and  halt  edges. 

Next,  to  each  outpoint  is  associated  a  predicate  ~  the  inductive 
assertion  —  which  is  intended  to  express  the  relation  holding 
among  the  values  of  the  program  variables  each  time  the  control 
peisses  that  outpoint.  The  desired  input  and  output  conditions  of 
the  program  serve  as  the  assertions  at  the  start  and  halt  outpoints, 
respectively.  Next,  a  verification  condition  is  constructed  for 
each  basic  path  —  a  path  which  begins  and  ends  at  two  (not  neces¬ 
sarily  different)  outpoints  but  does  not  pass  through  any  other 
outpoint.  The  verification  condition  for  a  basic  path  a  from 
outpoint  i  to  outpoint  j  states  that  if  the  assertion  at  i  is  true 
and  the  control  traverses  ot,  then  the  assertion  at  j  will  hold 
(with  the  new  values  of  variables  attained  at  j).  Finally,  each 
verification  is  proved  to  be  true.  By  induction  it  is  then  the 
case  that  the  assertion  at  each  outpoint  is  true  whenever  control 
reaches  that  outpoint  (assuming  that  the  input  condition  on  the 
start  edge  is  satisfied  at  the  initiation  of  progrcun  execution) . 

In  particular,  the  assertion  at  the  halt  edge  is  true  whenever 
control  reaches  this  edge,  that  is,  whenever  the  program  halts. 

Thus  the  program  is  partially  correct  with  respect  to  the  given 
input  amd  output  conditions. 

In  constructing  the  verification  condition  for  a  given  path, 

one  has  to  teUce  into  account  the  transformation  in  variable  values 

resulting  from  the  execution  of  the  statements  in  the  path.  For 

exan^le,  let  a  path  consist  of  a  single  assignment  statement 

x:sx+l  and  let  the  assertions  at  the  beginning  and  the  end  of  the 
2  2 

path  be  x  +2x+3>0  and  x  +2>0,  respectively.  The  verification  con- 

2 

dition  should  be  equivalent  to  the  statement:  If  x  +2x+3  is  true 

for  some  value  of  x,  emd  the  assignment  x:=x+l  is  executed,  then 
2 

X  +2>0  is  true  for  the  new  value  of  x.  Clearly  this  is  not 
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equivalent  to 

x^+2x+3>0  x^+2>0, 

2  2 

for  the  predicates  x  +2x+3>0  and  x  +2>0  hold  for  different  values 

of  x^  namely  those  respectively  before  and  after  the  execution 

of  x:=x+l.  We  can  "normalize"  the  predicates  so  as  to  make  them 

refer  to  the  same  values  of  x,  either  before  or  after  the  execution 

of  the  assignment  statement.  In  terms  of  the  values  existing  before 

2  2 

the  e^cution,  the  predicates  are  x  +2x+3>0  and  (x+1)  +2>0;  in  terms 

2 

of  the  values  after  the  execution,  they  are  (x-1)  +2(x-l)+3>0  and 
2 

X  +2>0.  The  verification  condition  can  then  be  written  in  the 
equivalent  forms 

x^+2x+3>0  O  (x+l)^+2>0 
or,  (x-l)^+2 (x-l)+3>0  x^+2>0. 

In  general,  suppose  the  assertions  at  the  beginning  and  the 
end  of  a  path  a  are  P  and  Q,  respectively.  Then  the  verification 
condition  for  the  path  is  a  predicate  P’&ROQ',  where  R  represents 
the  condition  under  which  a  is  traversed  (I^true,  if  a  does  not  contain 
any  conditional  statement),  and  P',  Q'  are  obtained  from  P,  Q, 
respectively,  by  making  appropriate  substitutions  to  reflect  the 
ch6Uiges  in  variable  values  effected  by  the  execution  of  statements 
in  a.  The  substitutions  should  be  done  so  as  to  make  P*  and  Q' 
refer  to  the  same  values  of  variables.  (R  should  be  derived  to  also 
correspond  to  the  same  values  of  variables.)  In  the  special  case 
that  the  predicates  are  to  be  expressed  in  terms  of  the  varieible 
values  at  the  beginning  of  the  path,  P'  is  just  P,  6md  Q'  is  formed 
from  Q  by  "backward  substitution"  [6] :  The  path  is  traced  backward 
and  for  every  eissignment  statement  encountered,  the  assigned 
expression  is  substituted  for  the  assigned  variable;  the  cimiulative 
effect  of  all  such  substitutions  is  to  transform  Q  into  Q* .  On 
the  other  hand,  if  the  predicates  are  to  be  expressed  in  terms 
of  the  variable  values  at  the  end  of  the  path,  then  Q’  is  just  Q, 
and  P'  is  obtained  from  P  by  2Ln  analogous  process  of  "forward 
substitution. " 

Since  the  lambda- calc  ulus  (13,91)  contains  built-in  rules  to 
carry  out  the  process  of  substitution,  it  is  possible  to  use 
a  lambda-calculus-based  method  for  the  automatic  generation  of 
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verification  conditions.  The  method  to  be  described  in  this 
paper  has  been  obtained  by  modifying  and  extending  the  lambda* 
calculus  model  of  programming  languages  described  in  [1].  This 
model  is  comprised  of  rules  for  translating  programs  written 
in  a  large  subset  of  ALGOL  60  (or  a  similar  language)  into 
lambda-expressions  in  such  a  manner  that  if  the  result  of  ex¬ 
ecuting  a  program  P  with  inputs  consists  of  outputs 

then  the  lambda-expression  ({P}  {i^^}. . .  {ij^^})  reduces 
to  the  tuple  or  list  <{Oj^} , . . . ,  {o^}>,  (Here,  denotes 

the  leunbda-calculus  representation  of  the  enclosed  object. ) 

Based  upon  these  rules ,  a  compiler  has  been  constructed  ( [ 5 ] ) 
to  translate  PASCAL  programs  into  lambda-expressions.  The  goal 
of  the  model  to  be  presented  in  this  paper  is  to  provide  rules 
for  treuislating  emy  program  suitadsly  annotated  with  assertions 
into  a  lambda-expression  whose  reduction  yields  a  list  of  the 
leunbda-calculus  representations  of  the  verification  conditions. 
To  distinguish  the  two  models,  we  call  the  former  the  "execution 
model"  and  the  latter  the  "verification  model". 


Before  giving  any  translation  rules  for  the  verification  model, 
we  must  specify  the  language,  call  it  PL,  in  which  the  programs 
acceptable  by  the  model  can  be  written.  This  language  contains 
the  following  feat\ires: 

1.  Integer  cuid  boolean  data  types 

2.  The  usual  arithmetical,  boolean,  and  relational  operators 

3.  Assignment  statements  of  the  form  variadsle  :=  expression 

4.  Input  cuid  output  statements  of  the  form 

read  variable  list 
write  expression  list 

5.  Conditional  statements  of  the  form 

if  condition  then  statement 

if  condition  then  statement  else  statement 

6.  Compound  statements  and  blocks  as  in  ALGOL  60. 

Inductive  assertions  associated  at  chosen  outpoints  in  a  flowchart  are 
incoirporated  directly  in  the  body  of  a  PL  program  by  means  of 
the  following  statements: 

7.  Assert  statement  of  the  form 

assert  assertion 

8.  Maintain-while  statement  of  the  form 

Maintain  assertion  while  condition  ^  statement 

The  features  (1)  to  (6)  have  the  usual  ALGOL  60  semantics. 

The  effect  of  the  execution  of  an  assert  statement  is  the  following: 
The  assertion  is  evaluated.  If  it  is  true,  then  control  passes 
to  the  next  statement;  if  false,  an  error  exception  occurs.  The 
effect  of  the  execution  of  a  maintain-while  statement  is  the 
following:  The  assertion  is  evaluated.  If  it  is  true,  then  the 
while-do  part  is  executed  according  to  the  usual  semantics;  if 
false,  an  error  exception  occurs. 

A  vaoriable  occurring  in  any  statement  (3)  through  (8)  (as 
a  left-hand  part  or  an  operand  in  any  condition  or  expression) 
must  be  a  variable  in  whose  scope  the  statement  occurs,  that  is, 
must  be  a  varied>le  in  the  "environment"  of  the  statement  (see  [1]). 
However,  a  variable  occurring  in  an  assertion  in  any  statement 
(7)  or  (8)  may  be  a  variable  of  the  environment  of  the  statement 


or  it  may  be  one  of  the  special  Vcuriables  vhere  m 

is  fixed  for  each  program.  Of  these  variables,  o  is  called  the 
output  variable,  and  ij  are  called  input  variables.  The  need 
for  these  variables  will  be  clear  later. 

PL,  the  source  language  for  our  verification  model,  is  much 
simpler  than  the  source  languages  used  in  the  execution  models 
of  [1,5],  yet  it  contciins  more  features  than  in  [6,7],  say.  The 
verification  model  can  be  easily  extended  to  include  in  PL  such 
features  as  multiple  assignments  of  ALGOL  60,  collateral  (parallel) 
assignments  of  ALGOL  68,  for  amd  repeat  statements  of  PASCAL, 
array  data  type,  and  functions  without  side-effects.  But  the 
incorporation  of  general  procedures  seems  difficult. 
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The  Verification  Model;  Preliminaries 

In  the  execution  model  11,5],  the  lambda-expression  repre¬ 
sentation  of  each  statement  (of  ALGOL  or  PASCAL,  say)  has  been 
derived  using  the  following  idea:  Each  statement  in  a  program 
may  be  thought  of  as  manipulating  1)  the  variables  accessible  at 
the  time  the  statement  is  executed  (these  constitute  the  statement's 
"environment")  ,  and  2)  cin  entity  identifying  the  point  in  the 
program  that  is  being  executed.  This  entity,  called  the  "continua¬ 
tion"  or  "program  remainder",  is  nothing  but  an  eventually  re¬ 
cursive  description  of  the  entire  portion  of  the  program  not 
executed  so  far.  The  statement  C2ui  therefore  be  translated  as  an 
edsstraction  with  respect  to  the  continuation  (denoted  by  the 
variable  <ji)  and  the  indeterminates  representing  the  program 
variables.  Referring  the  reader  to  11,5]  for  the  actual  details 
of  representation,  we  give  below  some  examples  of  translation  in 
the  execution  model, 

Exetmple,  Some  translations  in  the  execution  model 
Environment:  (x,y,x) 

Statement  Representation 

y:=x+3;  a=X<))xyz:<}>x(+x3)z 


if  y=l 
then 

z  :-0 

else 

x;®z+l ; 


b=X<))xyz :  (=yl)  cdcfixyz,  where 
c=A<j)xyz  :4»xy0 
d=X^xyz:<t>(+zl)yz 


while  y>x  do 
x:=x+z; 


esX(})xyz :  (>yz)  (f((»)(J)xyz 
f  E  X  <|ixy  z :  <1)  (+XZ )  y  z 


write  x+3;  gsX  j)xyzo  tjixyzo;  (+x3) 

read  x,z;  g=X<j)xyzoi2^i2 : <|>ij^yi20 

The  representation  of  variables,  constemts,  operations, 
relations,  and  expressions  in  the  verification  model  is  the  same 
as  in  [1,5],  But  when  translating  statements,  we  need  some  other 
constituents  besides  the  continuation  and  the  environment.  These 
are : 

Vauriable  Stacks.  There  is  a  fundamental  difference  between  the 
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execution  of  a  conditional  statement  for  a  nvunerical  result  emd 
the  symbolic  evaluation  for  generating  verification  conditions. 
Whenever  a  conditional  statement  is  reached  during  a  numerical 
execution,  some  condition  is  evaluated  emd  according  to  the 
result  of  the  evaluation,  the  first  or  the  second  branch  of 
the  statement  is  tadcen.  In  the  verification  context,  however, 
we  actually  have  to  execute  both  brainches  of  a  conditional 
statement,  and  moreover  it  is  essential  to  start  the  computation 
of  each  branch  with  the  same  values  of  the  various  progrcim  var¬ 
iables.  We  solve  that  problem  by  keeping  a  stack  for  every 
varieible.  Each  time  we  encounter  a  conditional  statement,  the 
current  values  of  the  program  variables  are  pushed  on  the  stack, 
and  when  we  pass  the  corresponding  ELSE  these  values  are  retrieved. 
Assertions.  Essentially  what  we  have  to  do  in  order  to  generate 
the  verification  conditions  for  a  progreun  is  to  traverse  every 
basic  path  of  the  program  between  inductive  assertions  and  output 
the  lemma: 

"assertion  at  start  point  &  path  condition  3  assertion  at  end 
point  with  appropriately  changed  values  of  variables". 

So  we  need  some  constituent  which  allows  us  to  store  the  asser¬ 
tion  of  the  start  point  and  successively  add  the  path  condition. 
This  leads  us  to  the  concept  of  an  assertion  constituent. 
Verification  conditions.  Whenever  a  verification  condition  is 
generated  we  want  to  store  it  in  some  constituent  which  finally 
will  be  the  output  of  the  whole  process. 

Thus  the  tr2mslation  of  a  statement  into  the  verfication  model  if 
of  the  following  form; 

A  4>  T  a  V,  o,  ...  v„  a„  9  iT...i„;  4)'t' 


progreun 

remainder 


rcunl  asser\  output  \  ^ 


■  '  o ' 

n  n 


y 


verification 
conditions 


program 

variables 


new  values  to  reflect  the 
effect  of  the  statement 


Following  are  some  definitions  and  abbreviations  that  will 
be  used  later: 

I  =  Ax:x  (Identity,  null  list  or  triple) 


n  =  (Xxy :xx) (Xxy :xx)  (Undefined  value) 


. .  ,a^>  =  Xx; 

xaj^ . . .  a^^ ,  n^r 

'  (list  or  triple) 

®11  ^  Xx:xl 

(Note : 

Sii<a>  -►  a) 

®21  ^  Xx;x(Xxy:x) 

(Note ; 

S2i<a,b>  ^  a) 

®22  ^  Xx;x(Xxy;y) 

(Note : 

S22<a,b>  -*■  b) 

a;b  =  Xx:axb 

(Note ; 

.  ,a^>  ;b  <a2/>«*r 

push  =  Xxy;<x,y> 

(Note : 

push  ads  -*•  <a,b>  *■  a;b 

push  <aj^, . . .  ,a^>b  <aj^, 

£0£  S  S22 

(Note : 

pop  <aj^,. . .  ,a^,b>  -►  b) 

add  =  Xxy : push ((s 

2iy)  &x)  (S22y) 

> 

(Note : 

add  a<b,c>  -►  <b&a,c>) 

ch  =  Xxzpush (s^^x)  )  (push (s 

!2j^x)  (S22  (^22^)  ) ) 

(Note : 

ch<a,<b,c>>  <b,<a,c>>) 

coinb  =  Xx:push((s 

21X)  v(S2i(S22 

,x) ) )  (S22  (S22X)  ) 

(Note : 

coinb<a,<b,c>>  <avb,c>) 

Translation  Rules 
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Using  the  notation  of  [1]  (to  which  the  reader  is  referred 
for  motivation  and  explanation) ,  we  now  list  the  translation  rules 
of  the  verification  model.  These  rules  have  the  form 

{S}g  =  the  lambda-expression  representing  statement  S 
in  environment  E. 

Assignment  statement 

{v. :=e},„  „  .  (e  is  an  expression) 

Input-Output  statement 

{read  . 

E  X4.Tuv^a^. . .  v^a^ox:<DTQtv^a^.  •  •  v. _^a .  _^xo .  v.  .  .v^a^o 


{write  e} 


(V.  f  m  •  •  .V  ) 


1 ' . n' 

=  X(|)TaVj^aj^, . .  v^a^o:(j)TaVj^a^. . .  v^o^o;  (e) 
Confound  statement 

{begin  2!ia>  Cv^ , . . . , vj 

=  X4):  {S^}({S2}C...  ({S^}(|))...)) 

Blocks 


{begin  <type>u^;. . . <type>u^;S^;S2; 

=  X(J)Ta:{Sj^}p({S2}p(,  . {Sp}j, (XxaUj^a^ 


...u  a  ;(bTa) )...))  xaQini. .  .fil 

1  m  u  \  - j 

1  m 


m  tiroes 

where  F  =  environment  extended 

by  the  newly  declared  variables  of  the  block. 

Since  in  the  verification  model  the  current  assertion  a  cuid  the 
list  of  verification  conditions  x  precede  the  representation  of 
the  varicUsles,  we  have  to  include  a  and  x  in  the  specification  of 
a  block. 

For  every  new  variable,  which  is  introduced  by  the  block, 
we  need  a  stack.  This  stack  is  initially  enpty  (I)  and  has  to 
be  deleted  at  the  end  of  the  block  together  with  the  variable. 
Conditional  Statements 


{if  b  then  S.  else  S,},  „  „  » 

—  1  2Cv^,...,v^> 
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=  X(j(:M  (su({S2}  (sc  <|>)))). 

Subsidiary  definitions: 

as  =  X(j)TaVj^Oj^. .  .v^a^;(j)T  (£ush(s22“  &  b)  (add(~b)  a) 

Vj^(push  . .  .v^(push  v^a^) 

This  takes  the  first  part  of  the  assertion  (which  represents  the 

valid  assertion  at  the  point  of  the  condition  statement)  S2]^oi  eund 

creates  two  versions  of  it,  which  in  addition  to  825^01  also 

assume  b  or  ~b,  respectively.  Furthermore,  the  current  values  of 

the  variables  are  pushed  onto  their  stacks.  This  is  necessary, 

because  now  we  want  to  perform  the  statement  {S^^},  which  might 

change  the  values  of  the  variables.  But  we  need  these  values 

for  the  execution  of  {S2}  later  on. 

su  2  X(J)Tav,a- . , .  v^a^  :<j)T  (ch(add(v,=v,  &  ...  &  v„=  v„)a)) 

—  11  n  n  —  -  11  n  n 

^®2l'^l^  (E2E  ^1)  •••  (pop 

This  saves  the  results  of  the  execution  of  {S^^}  by  adding  them 

to  the  current  assumption.  Now  we  are  ready  to  switch  the  first 

two  branches  of  the  "assun^jtion  tree" ,  which  causes  the  version 

containing  "b  to  become  the  current  ass\jroption.  For  the  following 

execution  of  ^82}  we  delete  the  action  of  {Sj^}  on  the  variables 

and  restore  their  old  values,  which  is  achieved  by  ^stacking  them. 

sc  =  X(j>TaVj^aj^.  ..v^a^;<jiT(  comb  (add  (V]^=Vi  &  •••  &  ^ 

Vl-'-Vn 

This  finally  saves  the  results  of  the  execution  of  {S2}  by  adding 
them  to  the  current  assxamption.  Afterwards  the  assumptions  for 
the  then  and  else  clauses  are  combined  to  a  single  one  by  disjunction. 
Since  the  results  of  both  {S^^}  and  {S2}  are  now  saved  in  the  current 
assertion  and  are  denoted  by  v^,  we  make  v^  the  new  value  of  v^. 

Note:  The  second  form  of  IF-statement 
{if  b  then  S),^^ . 

is  translated  into 

X(|):^({Sj^}  (su(I  (sc  ({»)))) 
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Assert  statements 


{assert  a(Vj^,. . ,  ,v^,o)  } 

=  X(t)Tav^aj^. . .  v^o^o' :(j)T;  (s22Q‘^2i*  )  (sub  a  a) 


V,  a, . . .v^a^o 
11  n  n 


where 


a'  =  a(vi,...,v;^,o') 
s\ib  H  Xxy  tpush  x  (S22y) 

The  lemma:  "current  assertion  =>  a  with  the  varieJjles  replaced 
by  their  current  values"  is  added  to  the  verification  conditions. 
Afterwards  the  current  assumption  is  replaced  by  the  assumption 
a  euid  we  delete  the  former  values  of  the  variables. 

Main tain-while  statement 

{maintain  a  while  b  do  S} 

=  XctTav^a, . .  .va^  :ast  Cad,  ({S}  (ast  (ad^ij)) ) ) )  Tav,a, , .  .v^o^ 

where 

ast  =  X<|)Tav^a^. . .  v^a^o' :<|)T  ;  (S2j^ctOa' )  (sub  a  a) 

v,a. . . .v„a  o 
IX  n  n 

is  a  representation  of  the  statement 
assert  a, 

ad,  =  X(i)Tav-,a-i » « .v_a_  :(|>T  (add  b  a)  v,a,...v^a„ 
adds  the  predicate  b  to  the  current  assumption. 

Now  the  statement  {S}  is  performed  emd  afterwards  "ast"  checks 
whether  the  predicate  a  has  been  maintained.  This  procedure  sets 
up  the  necessary  verification  conditions  for  the  maintain-while 
statement.  What  remains  to  te  done  is  to  add  ~b  to  the  current 
eissximption  and  examine  the  program  remainder: 

ad^  =  XctxaVj^cfj^. . .  Vj^a^:(JiT  (a^C'b)  a)  •  •’'^n^n* 


Exang>les  of  Translations  from  PL  into  the  Lambda-calculus 

We  now  present  some  examples  of  tremslations  of  programs 
obtained  by  using  the  rules  presented  above.  The  program  statements 
have  been  tagged  with  identifiers  used  as  the  neones  of  the  cor¬ 
responding  lambda-expressions.  In  writing  Icunbda-expressions , 
certadn  notational  liberties  have  been  tedcen  in  order  to  ntcUce 
them  human-readable;  the  intended  correct  form  must  be  obvious  in 
these  cases.  Thus,  expressions  have  been  written  in  the  usual 
infix  notation,  rather  than  the  proper  postfix  launbda-expressions. 
Fcr  excunple, 

[gcd(n,m)  =  gcd(x,y)  &  x^O  &  y^O] 
has  been  used  as  a  shorthand  for 

(&(&  (=  (gcd  n  mX  gcd  x  y) )  (^  x  0) ) (^  y  0) ) . 

The  result  of  reductions  given  at  the  end  of  each  example  has 
been  obtained  by  means  of  a  computer  progreun  [2]  which  reduces 
lambda-expressions  to  their  simplest  (normal)  forms.  The  actual 
computer  print-out  is  included  with  one  example. 

Example  1,  Summation  of  a  given  number  of  consecutive  integers. 
Input  condition:  n^O  (n  is  input) 

Output  condition:  output  * 


begin  integer  m,s;  . . p 

read  m;  (*The  value  n  is  assigned  to  variable  m*) . re 

s:=0;  . . . . al 

begin  integer  j;  . bAl 

js=l;  . a2 

maintain  . . . . 

s='(j-l)*j/2  ctnd  m=n  and  j^m+1 . ast 

while  j^m  ^  . adl ,  ad2 

begin  . bJl2 

s:=s+j;  . . . a3 

j:=j+l  . . . a4 

end 

end; 


write  s;  (*  s  is  appended  to  the  (currently  empty)  output* .wr 
file  o.  Thus,  Sj^j^O“s  *) 


assert  =  m*(m+l)/2  . ter 

end 

Final  Result . res 


Translations 

re  =  Xixa  ma^so  oi,  :  (|>Tai, o^sa^o 
insl  ims 

al  =  X(})Ta  ma_sa_ :  <|)Toiina_Oa 
ms  ms 

a2  =  X())Taj  :  4'Tal 

ast  E  X(J)Taj '  0  .m'a  s*a  :  (|)  (t  ;  (s»,  a:3  [s  *=  (j '-1)  *j '/2  &  m'=n'  &  j'^m+1])) 

J  HI  S  A  A 

(sub  [s=(j-l)*j/2  &  in=n  &  j<i!H-l]ot)  ja.ma  sa 

adl  =  X j)Ta; 4>t (add  tj^m]a) 

ad2  =  X(^Ta;(^T  (add  [j>m]a) 

a3  =  X(|)Taja  .mo  S0„  ;<()Taja  .ma„Is+j]a^ 

a4  =  X(|)Tajo  j  :(j>T0i[  j+HOj 

b£2  =  X(j):a3(a4  <{)) 

mw  =  X4>:ast  (adl(bl2(ad2  (|>)))) 

bil  =  X(|)To:a2  (inw(XTajaj  ;(|)Ta) )  xafll 

wr  =  XAtamo  sa„o:(()Tama  sa„  (o;s) 

^  ms  ms 

ter  =  X(t>Tam’0j^s'agO' :<j)(T;  (s2]^aDISj^j^o'=m'*(m'+l)/2]) ) 

(sub  (s2^j^o=m*(m+l)/2]a)  mcr^sagO 
p  =  X4»Ta:re(al(bAl  (wr(ter(XTama^sa^:4>Ta) ) ) ) )  TaJ2If2I 
res  =  p(XTaoiT)  I  •<;n^0,I>  In 

By  lambda-calculus  reduction,  we  obtain; 
res  -*•  <  [n^O  ^  0=0  &  n=n  &  l<n+l]  ,  [s=i-^— &  )l=n  &  i^H+l  &  i^2. 

s+i  =  &  ian  &  i+l=Jl+l] ,  Is=^-^  --^  &  Jl=n 

&  i^H+l  &  i>Jl  s=^ 

Thus,  res  is  a  list  containing  the  three  required  verification 
conditions.  It  is  eeisily  seen  that  each  of  these  conditions  is 
true.  So  the  program  is  partially  correct  with  respect  to  the 
specified  input  and  output  conditions. 
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Exanple  2.  Square-root  program. 

Input  condition:  n^O  (n  is  input) 

2 

Output  condition:  output  =  max  k  >n 

k>0  " 


begin  integer  x,yj^,y2,y3;  . p 

begin  . aa 

read  x;  (*  The  value  n  is  assigned  to  variable  x  *),..re 
(yi/y2^y3)  ;  . al 

y2*-*y2+y3  . a2 

end; 

maintain  mw 

2  2 

x=n  and  y^^^n  and  y2=(y^+l)  and  y3=2*yj^+l . ast 

^bile  y2<x  do  adl,ad2 

Cy3^/y2»y3)  s=(yi+i»y2'‘-y3+2,y3+2) ; . bb 

write  . wr 

(*  y^^  is  appended  to  the  (currently  empty)  file  o.  Thus, 

*>  , 

assert  (Sj^j^o)^^n  and  n<  ( (Sj^3^o)+l) . ter 

end 

Final  Result . res 


Translations 

al  =  y3°y3‘*^“”a®‘’yj^'>°y2^'’y3 

=  ■'♦^'“Vl'’y3l'2°y2S^3'’y3  =  *^"“'xyi“y3'i'2*y3>‘’yjy3'’y3 

aa  =  A4):re(al(a2  (p)} 

ast  =  X(j)Tax'o^J^ay  y^o^  y^a^  :(fr{T;  (S2JLar>  [x'=n  &  y^^<n 

«L  2  3 

&  y^-(yi+i)^  &  y^-2*yj^+i])) 

(8^  Ix-n  &  yj<n  &  y2-(y2^+l)^  &  yj^2*y^+l]  a)  y^cr^  y^a^ 

12  3 

adl  =  X^Ta:^T  (add  Iy2i,x]o) 
ad2  =  X(^Ta:(^T  (add  [y2^x]a) 

bb  5  HTa»J^3ey^yjOy^y30y^.,To»J^Iy3+lley^iy2+y3+21ey^(y3+2]ey^ 
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nw  =  X(^:ast(adl(bb(ast(ad2  ()>)))) 

ter  =  ^♦Toix'o^J^a  yJOy  y^Oy  o' scKtj  (Sj^^o  :>(  (Sj^j^o*  )^<n  i  n<  ( (Sj^j^o' )+!?])  ) 

(sub  I(Sj^j^o)^^n  &  n<((Sj^^o)+l)  ]a)  xa^^^Oy  y^a^  o 

12  3 

p  =  X(|)Ta:aa(iEw(wr(ter  (Xtoixa^^ay  y2^y  ^2°y  * 'fTct) ) ) )  TaSJininiJJI 

12  3 

res  =  pCXtuoit)  I  <n>0,  I>  In 


By  lainbda-calculus  reduction,  we  obtain: 
res  -»•  <[n^0  O  O^n  &  1=1  &  1=1  &  n=n] , 

[y^<n  &  y2=(y2+l)^  &  y3=2yj^+l  &  x=n  &  y2<x 

r>(yi+l)^ln  &  y2+y3+2=  (y^^+l+l)^  &  y3+2=2  (yj^+1) +1  &  x=n] , 

ly^^n  &  y2=(y3^+l)^  &  y3=2yj^+l  &  x=n  &  y2>x 
^yjin  &  n<(yj^+l)^]> 

Thus,  res  is  a  list  containing  the  three  required  verification 
conditions.  It  is  easily  seen  that  each  of  these  conditions  is 
true.  So  the  program  is  partially  correct  with  respect  to  the 
specified  input  and  output  conditions. 


Example  3,  GCD  calculation. 

Input  condition:  n^O  &  m^O  (m,n  are  inputs). 
Output  condition:  output  =  gcd(n,m) 


begin  integer  x,y;  h 

read  x,y;  (*  Input  values  n,m  assigned  to  x,y  *) . a 

maintain 

gcd(n,m)=gcd(x,y)  &  x^O  &  y^O . ast 

while  x^y  ^  adl,ad2 

if  x>y  then  ,.,, . as,sc,d,e 

x:=x-y  ,.b 

else  . su 

y:=y-x;  ,.,,c 

write  x;  f 


(*  Value  of  X  appended  to  (currently  empty)  output 
file  o.  Thus  Sj^j^o=x  *) 


end 


assert  gcd(n,m)=Sj^j^o 
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Final  Result . res 


Translations 

a  i  X(j)Ta  xa^ayOi^i2:(tiTaij^a^i2ayO 

ast  =  X(|)Tax'a^'ay  ;(i)(T;  (S2j^a  ^Igcd(n,m)=gcd(x' ,y' )  &  x'^0  &  y'^0])) 
(sub  [gcd(n,in)=gcd(x,y)  &  x^O  &  y^0]a)xa^ay 
adl  =  X  j>Taxa^^a..  ;4)t  (add  [x-^y]  ot)  xg^^yg„ 
ad2  i  X())Taxa^^a„ ;  jit  Caddlx=y1  a)  xa^^(y„ 

as  =  X(t)Taxo^^a„;(i)T  (pushCs^j^a  &[x>y] )  Caddlx<yl  a)  )x(push  xa^^)y(push  ya„) 
b  =  X())Taxo^ay  :(|)Ta[x-y]a^ay 

su  H  X  j>Taxa^ya„ ;  ({>Tch  (addla^x  &  y*=y]a)  Cs23^cr^rGEO£  cr^J  Cs2.Lcry5  CPOP  a^) 

c  E  X(|)Taxa^ay  ;(i)Taxa^[y-x]ay 

sc  =  X(j)Taxa^^a„;<j)TConib  Caddl5^x  &  y=y']a)xa^ay 

d  =  X<j)  ;as  (b  (su(c  (sc  <|))))I 

e  =  X(|)  ;ast  (adl  (d(ast  Cad2 

f  =  X(J)Taxa^ayO!(J)Taxaj^ay  Co;x) 

g  =  X<j)Tax'aj^'ayO’ :<j)CT;  Cs2ia  3lgcd(n,inJ*Sj^j^o’]  )  1 
(sub  [gcd  (n  ,in)  =s^  a )  xa^a^o 

h  =  X(j)Ta:a(e(f  (gCXta  xa^c^  :4)Ta) ) ) )  xamni 
res  =  h (Xtco :t) I< [n^O  &  m^Ol ,  l>  I  n  m 


By  lambda-calculus  reduction,  we  obtain 
res  -►  <  [n^O  &  m^O  ^  gcd(n,in)=®gcd(n,m)  &  n^O  &  m^O] , 

[gcd(n,m)*gcd(x,y)  &  x^O  &  y^O  &  x?^y  &  x£y  &  x=x  &  y®y-x 
or  gcd(n,m)=gcd(x,y)  &  x^O  &  y^O  &  x/y  &  x>y  &  5c=x-y  &  y*y 
3  gcd(n,m)=gcd{x,y)  &  3c>0  &  y^O] , 

[gcd(n,m)=gcd(x,y)  &  x^O  &  y^O  &  x=y  3 gcd (n ,m)  =x] > 

Thus,  res  is  a  list  containing  the  required  verification  conditions.  As 
each  verification  condition  is  true,  the  program  is  partially 
correct  with  respect  to  the  specified  input  and  output  conditions. 


Translations  of  individual  statements  into  the  lambda- calculus 
(Note :  L  stands  for  X  on  conqputer  input. ) 


1  -  (L  PHI  (L  TAU(L  AL(L  VX(L  SX(L  VI  (L  SI  (L  01  (L  11  (L  12 
(PHI  lAO  AL  II  SI  12  SI  01))))))}}))). 

•  % 

AST  =(L  PHI(L  IA0(L  AL  (L  VXP(L  SX  (L  VIP(L  SI  (PHI  (PSfi  TAD 

((S21  AL)inP  (tCU  (GCE  N  H)  (6CD  VXP  VIP)  AND  (G£  VXP  0) 

AND  (G£  VIP  0))}) 

(SUB  (ECO  (GCD  N  H)  (GCC  VX  VI)  AND  (G£  VX  C)  AND 
(GE  VI  C))  AL)  VX  SX  VI  SI)))))))). 

ADI  =(L  EHI(L  TA0(L  AL  (L  VX  (L  SX  (L  VI  (L  SI  (PHI  TAD  (ADD 
(N£  VX  VI)  AL)  VX  SX  VI  SI)))))))). 

AD2  =(L  PHI(L  TAU(L  AL(L  VX(L  SX  (L  VI  (L  SI  (PHI  TAU  (ADC 
(EQU  VX  VI)  AL)  VX  SX  VI  SI))))}))). 

AS  =  (L  PHI  (L  1AU(L  AL  (L  VX  (L  SX(I  VI  (L  SI  (PHI  TAU  (PSH 
((S21  AL)  AND  (GT  VX  VI))  (AEE  (LE  VX  VI)  AL)  )  VX 
(PSH  VX  SX)  VI  (PSH  VI  SI))))))))). 

BB  a  (L  PHI(L  TA0(L  AL(L  VX  (L  SX(L  VI  (L  SI  (PHI  TAU  AL 
(-  VX  VI)  SX  VI  SI  }))))))). 

SO  a  (L  PHI(L  TAU(L  AL(L  VX(L  SX (L  VI(L  SX  (PHI  TAD  (CH 
(  ACD  ((EQU  VXB  VX)  AND  (EQU  VIB  VI))  AL)  )  (S21  SX) 

(S22  SX)  (S21  SI)  (S22  SI)))))))))  . 

CC  a  (I.  phI(L  TAU(L  AL  (L  VX(L  SX  (L  VI(L  SI  (PHI  TAU  AL 
VX  SX  (-VX  VX)  SI)))))))). 

sc  a  (L  PHI(L  TAU  (L  AL  (L  VX(L  SX(L  VI  (L  SI  (PHI  TAU  (COC 
(ADO  ((EQO  VXB  VX)  AND  (EQU  VIB  VY)}  AL)} 

VXB  SX  VIB  SI) )))))) )  . 

D  a  (L  PHI  (AS  (BB  (SO  (CC  (SC  PHI})}}}}. 

E  =  (L  PHI  (AST(AD1  (D  (AST  (AD2  PHI)))))), 

F  a  (L  PHI(L  TAU(L  AL  (L  VX(L  SX  (L  VI  (L  SI  (L  01  (Phi  TAD  AL 
VX  SX  VY  SI  (PSH  01  VX) })))})))}  . 

G  a  (L  PHI(L  TAU(L  AL  (L  VXP(L  SX (L  VYP(L  SI  (L  OF  (Phi 
(PSB  TAU  ((S21  AL)  IMP  (EQU  (GCC  N  H)  (S11  OP)))) 

(SOB  (EQO  (GCD  N  H)  (S11  01))  AL)  VX  SX  VI  SI  Cl))))))))). 

Ha  (L  PHI(L  TAU(L  AL  ((A  (£  (F  (G  (L  TAD  (L  AL  (L  VX  (L  SX  (L  VI 
(L  SI  (PHI  TAU  AL)  )))))))))  )  TAU  AL  CC  I  CR  I) }  )  )  . 

BES  aH(L  1AU(L  AL  (L  OUT  TAU) )  )' I  (PSH  (GE  N  0  AND  GE  K  0)1)1  N  L. 


Definition  of  auxiliexy  objects 
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PSH  ^(L  A  (L  B  (L  1  (X  A  B)  )  )  )  . 

SEC  = (L  X  (L  Y  I) ) . 

Sll  =T  I.  (Alternative  definition —  T  =  x^xysyx  is  a  primitive) 

521  =T  K. 

522  =T  SEC. 

SUB  ={L  VX  (L  VY  (PSH  VX  (S22  VY)))J. 

ADD  ={L  VZ(L  X  (PSH  ((S21  X)  A  SD  V2)  (S22  X)))). 

CH  =  (L  VZ  (PSH  (S21  (S22  VZ) )  (PSB  (S21  VZ)  (S22  (S22  YZ))))). 

COK  =(L  VZ  |(PSH  (OB  (S21  VZ)  (S21  (S22  VZ)  )  )  )  (S22  (S22  VZ)))). 

Now  RES  should  reduce  to  a  list  of  three  verification  conditions. 
Due  to  the  definition  of  lists,  RES  has  the  form  <<<P>,Q>,R>. 

The  coni>onents  are  extracted  below  in  the  order  R,  Q,  and  P. 


S22(S21  (S21  RES)). 

INPUT  OBJECT  IS... 

:  S22(S21(S21  RES)) 

REDUCED  OBJECT  IS... 

GE  M  0  AND  GE  n  0 

inP  (EQU  (GCD  N  K)  (GCD  N  R)  AND  (GE  N  0)  AND  (GE  H  0)  ) 


S22(S21  RES)  . 

INPUT  OBJECT  IS... 

:  S22(S21  RES) 

REDUCED  OBJECT  IS... 

OB  (EUO  (GCD  N  B)  (GCD  VX  VY)  AND  (GE  VX  0) 

AND  (GE  VY  0)  AND  (N£  VX  VY)  AND  (LE  VI  VY) 

AND  (EQU  VXB  VX  AND  (EQU  VYB  (-VY  VX)))) 

(Ego  (GCD  N  K)  (GCD  VX  VY)  AND  (GE  VX  0) 

AND  (G£  VY  0)  AND  (N£  VX  VY)  AND  (GT  VX  VY) 

AND  (EQU  VXE(-  VX  VY)  AND  (EQU  VYB  VY)  )  ) 

IBP  (Ego  (GCD  N  B)  (GCD  VXB  VYB)  AND  (GE  VXE  0) 
AKC(GE  VYE  0)) 


S22  B£S. 

INPUT  OBJECT  IS... 
:  S22  hlS 


BEDUCED  OBJECT  IS... 

EQU  (GCO  K  tS)  (GCO  VX  VT)  AND  (G£  VX  0)  AND  ( GE  \l  Y  0) 
AND  (EuO  VX  VX) 

IBP  (ECO  (GCO  N  H)  VX) 
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The  Correctness  of  Verification  Model 

We  would  now  like  to  prove  that  the  verification  model  pre¬ 
sented  cdsove  is  correct.  In  other  words ,  we  would  like  to  show 
that  the  trams lation  of  a  PL  program  according  to  the  above-given 
rules  indeed  reduces  to  a  list  containing  the  lambda-calculus 
representation  of  all  verification  conditions.  We  begin  with 
some  definitions : 

A  path  a  in  a  PL  program  is  said  to  be  basic  if  it 
— starts  with  an  "assert"  or  "maintain"  or  starts  at  the  beginning 
of  the  prograun, 

— ends  with  an  "assert"  or  "maintadn",  and 
— does  not  contain  any  other  "assert"  or  "maintain". 

The  verification  condition  for  a  basic  path  a  with  starting 
assertion  q,  terminating  assertion  p  amd  path  condition  y  (the 
condition  under  which  y  is  traversed)  is 
q  &  y  =>  p, 

where  the  variables  in  q  are  replaced  by  the  result  of  performing  a. 

The  verification  condition  list  for  a  PL-program  is  a  list  of 
verification  conditions  of  all  its  basic  paths. 

The  predicate  after  am  "assert"  or  "maintain"  is  referred  to  as 
an  assertion. 

With  these  definitions  the  following  theorem  holds. 

Theorem:  If  the  assert  (amd  maintain)  statements  in  a  PL-program 
P  contain  only  program  variables,  symbols  i^,...,i^  for  the  input, 
the  symbol  o  for  the  output  amd  constants,  and  {prog}  is  a  translation 
of  P  into  the  verification  model,  and  is  the  input  assertion, 
then 

{prog}  (Xtuoit)  I  <aQ,I>  I 
generates  the  verification  condition  list  for  P. 

Proof: 

(XTao:T)  as  the  final  program  remainder  deletes  all  the  information 
but  T,  the  verification  condition  list. 

(*) 

We  show  that  for  cd.1  basic  paths  leading  from  assertions  q^f^'rq]^ 
via  path  conditions  to  the  assertion  p  in  a  PL-program, 

(*)  Some  of  the  q^'s  may  be  equal. 
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the  corresponding  translation  into  the  verification  model  generates 
the  verification  conditions 
qi  &  =>  P(x) 

eUld 


and 

’k  ‘  '<k  S’® 

and  adds  them  to  t,  the  list  of  verification  conditions,  x 
denotes  the  values  of  the  variadiles  immediately  before  the 
assertion,  possibly  also  contaiining  the  value  of  the  output  var¬ 
iable  o. 

Proof  by  structural  induction: 
basis ; 

q  and  p  follow  each  other  immediately,  after  execution  of  assert  q, 
is  q. 

The  path  cond.  y  =  T, 

The  variables  hold  Xj^,.,.,x^. 
assert  p  generates  the  lemma 

Plx=x 

v^ich  is  true. 
induction  step: 

(a)  Suppose  the  hypothesis  holds  for  arbitrary  p in  a 
PL-program.  Now  consider  a  PL-program  where 

Xi-**e(X3^,...,Xj^); 

assert  r 

is  substituted  for 
assert  p. 

Let  a  denote  the  stack  of  assertions  before  the  execution  of  the 
assignment,  which  is  the  same  as  the  one  in  the  original  program 
before  assert  p. 

Let  X  be  the  variable  values  before  the  assignment. 

If  we  now  let  p(x)  =  r(Xj^,. . .  ,x^_j^,e(Xj^,, . .  ,x^)  . .  ,Xj^) 

we  know  from  the  hypothesis 

s...  a  ■>  p I  — 

21  *^'x*x 

is  equivalent  to 


f  •  •  •  f 


k 

and  furthermore  to 

/\  ^  Yj-  ->  x=  . .  ,e(Xj^,. . .  ,x^) .  .x^) ) 

j®“i  /  *  •  •  /k 

(b)  Suppose  the  hypothesis  holds  for  arbitrary  P/q^,...,qj^  in  a 
PL-program.  Now  consider  a  program  where 
begin  <type>  u^, . . .  ,<type>  u^^^; 
assert  r  » •  •  •  / Ujj^  x^^  ^  •  •  •  / 
is  substituted  for 
assert  p. 

Let  a  denote  the  stack  of  assertions  before  the  execution  of  the 
assignment,  which  is  the  same  as  the  one  in  the  original  progreun 
before  assert  p. 

Let  X  be  the  varicible  values  before  the  begin. 

If  we  now  let 

p(x)  =  r(fl, . . .  ,£2,x,  .  ,x„} 

^  _  ‘  X  n 

m 

we  know  from  the  hypothesis 
=21“ 

is  equivalent  to 

A  ‘'5j  =  Plx>x> 

j=l , . . . ,k 

and  furthermore  to 

A  ‘ ’'j  ■^lu-cni,x=x' 

j*l , • • « /k 

Cc)  Suppose  the  hypothesis  holds  for  arbitrary  p,q^f...,qj^  in  a 
PL-program,  Now  consider  the  program  where 
end;  ( <type >u , . . . ,  <type >Ujjj) 
assert  r  (x^, . . .  ,Xj^) 
is  substituted  for 
assert  p. 

L^t  a. . .  stack  of  assertions  before  end 
X,  u. . .  variable  values  before  end. 

(1)  Uj^  did  not  overwrite  some  global  variable  x^.  Then  if  we  let 

p(Uj_,...  ,Ujjj,Xj_,...,x^)  :-r(Xj_,...,x^) 
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we  knew  from  the  hypothesis: 

®2l“  Plu«u,x»x 
is  equivalent  to 

A  ^'*j  ‘  ’fj 

j“l ^ f k 
and  futhennore  to 

/\  (<3j  S  Yj 

,k 


(2)  If  however  overwrote  the  global  variable  Xj  ,  we  could 
chcuige  the  name  of  u^^,  so  that  this  phenomenon  does  not  occur 
and  we  get 

A  ‘■Jj  ‘  ifj 

j=»l,..  .,k 

(d)  Suppose  the  hypothesis  holds  for  arbitrary  p^q^r •  •  •  in  a 
PL-program.  Now  consider  the  program  where 
^  b  ,  ,Xjj)  then 

assert  r 

is  substituted  for 

assert  p  (Xj^ , , . .  ,x^) , 

Let  a. . .  stack  of  assertions  before  ^ 

X. . .  variable  values  before  if 
The  execution  of  the  changes 

a  *  to  <a^&  b(x),<a£  &  ~b(x),...» 

and  leaves  x  \inchanged. 

If  we  let 

p(x)  *  (b(x)  «>  r(x)) 
then  we  know  from  the  hypothesis  that 

®2l“ 

generates  the  correct  verification  conditions 
/\  (qj  &  Yj  ->  p(3cn . 

j“l/ • • • /k 

So 

82j^o  6  b(x)  •>  r(x) 
which  is  equivalent  to 


®2l“  (b(x)  ■>  r(x)). 


Also  generates 

/\  (qj  &  Yj  =>  P(x)) 


(qj  &  Yj  S  b(x) 


which  are  the  correct  verification  conditions  for  the  paths 
leading  to  assert  r  in  the  modified  program. 
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=>  r(x)) 


(e)  Suppose  the  hypothesis  holds  for  arbitrary  in 

a  PL-progreun.  Now  consider  the  prograun  where 
if  b(x)  then 


else 

assert  r(x) 
is  sijbstituted  for 
Msert  p. 

Let  a...  stack  of  assertions  before  x...  variable  values  before  if 
The  execution  of  ^  changes 

a  =  to  <aj^  &  b{x),<aj^  &  ~bCx),...>> 

and  puts  the  values  x  on  the  variable  stacks. 
else  causes 

&  ~b(x),...>>  to  be  changed  to  <a^  &  "bCx) 
and  the  variable  values  are  retrieved  from  the  stacks.  A  reasoning 
analogous  to  that  in  (d)  now  causes  S2]^oi  &  ~b(x)  =>  r(x)  to  be 
equivalent  to  the  correct  verification  conditions 
/\  Cqj  &  Yj  S>  ~b(x)  =>  r(x)). 
j*l r . . . /k 

(f)  Suppose  the  hypothesis  holds  for  arbitrary 

q^f  q^»  p®,  q®»...f  q®  in  a  PL-program 


if  b  (x)  then 

begin 

• 

•  t 

assert  p  (x) 

end 

else 

begin 

• 

*  e 

assert  p  (x) 

end; 

6 

Now  consider  the  program  where  assert  p  f  p  are  eliminated  and 
replaced  by  assert  r(x)  after  the  if- statement. 


if  b (x)  then 
begin 

&nd 

else 

begin 


end; 

assert  r(x) 

Let  a...  stack  of  assertions  before 
a'...  stack  of  assertions  before 
a"...  stack  of  assertions  after  if-stateinent 
x^. .  •  variable  values  before  p*^ 

3^...  variable  values  before  p^* 

From  the  induction  hypothesis  we  know 

is  equivalent  to 

A  ^  *  Yj 

j“l,. . . ,k 
and 

®21®' 

is  equivalent  to 

A  *  Yj  P®(5^))  * 

j*l  f  •  •  •  th 

a'  ■  <S2]^a' ,<S2j^o  &  3c“X^,...>> 

o"  ■  <(S22a  &  3i=x^)  v  (S2j^a'  &  3c=x®),.,.> 

the  variable  values  after  the  if-statement  are  x. 

Let  p^(x)  =  (3c»x  ->  r(x)) 


So 


p®  (x)  =  (3c«x  ■>  r(x) ) 


®2l“" 


is  equivalent  to 


^®2l“  *  r(x))  &  {s,,a'  &  3c»x®  »>  r(x)) 


21 


or 


<«■> 


(S2JL®  p®(x®)) 


’21' 


/\  (qj  &  Yj  ->  r(3^))  &  /\  (q®  &  Y®  ->  r(: 

j“l»*«»»k  j*lf»««/L 

idiich  are  the  correct  verification  conditions. 


(g)  Because  of  (a)  -  (f)  we  know  that  for  all  PL-progreuns  without 
while- loops  the  model  generates  the  verification  conditions. 

Now  suppose  there  are  k  basic  paths  from  q^f  leading  to 
maintain  p(x) 
while  b{x)  ^ 

S 

We  want  to  add  the  lemmas 

qj  &  Yj  =>  P(x) 

to  T ,  where  x  denotes  the  variable  values  immediately  before  the 
maintain-vdiile  statement. 

We  know  by  induction  hypothesis  that  if  we  replace  this  maintain- 
while  statement  by 
assert  p(x) 

the  model  will  generate  these  verification  conditions  at  that 
point.  But  we  observe  that  the  first  step  in  the  translation  of 
the  maintain-while  statement  is  exactly  to  perform  this  assertion 
Thus  the  desired  effect  is  achieved. 

The  only  way  of  entering  the  statement  S  is  through  assuming  p (x) 
and  b(x)  (which  is  carried  out  in  the  second  step  of  the  trans¬ 
lation  of  maintain-while)  and  we  can  leave  it  only  by  asserting 
p(x}  again. 

That,  however,  is  exactly  the  way  of  processing 
assert  p(x)  &  b(x) 

S 

assert  p (x) 

in  the  verification  model. 

So  we  know  by  induction  hypothesis  that  for  all  the  basic  paths 
ending  in  S  or  leading  back  to  the  top  of  the  maintain-while 
statement,  the  correct  verification  conditions  are  added  to  t. 

Finally  we  want  to  start  a  new  basic  path  by  assuming  p(x)  &  b(x) 
and  that  is  exactly  what  happens  in  the  model. 


References 


29 


1.  Abdali,  S.  Kamal:  A  lamb da- calculus  model  of  programming 
languages  Part  I  &  II.  Journal  of  Computer  Langtiages^  1, 
pp.  287-320,  1976. 

2.  Abdall,  S.  Kamal:  "CL(MJE  -  a  combinatory- logical  normal 
form  evaluator,"  User's  Memual,  Rensselaer  Polytechnic 
Institute,  Troy,  NY,  1978. 

3.  Church,  A.;  The  Calculi  of  Lambda-Conversion.  Princeton 
University  Press,  NJ,  1941. 

4.  Floyd,  R.  W.  :  Assigning  meanings  to  prograuns.  Math.  Aspects 
of  Computer  Science.  J.  T.  Schwartz,  Ed.,  Amer.  Math.  Soc. , 
Providence,  R.I.,  1967,  pp.  19-32. 

5.  Kaltofen,  Erich  &  Abdali,  S.  Kamal:  An  attributed  LL(1) 
compilation  of  Pascal  into  the  lambda-calculus.  Tech.  Report, 
Rensselaer  Polytechnic  Institute,  Troy,  NY,  June  1981. 

6.  King,  James  C. :  "A  program  verifier,"  Proc  IFIP,  1971, 
pp.  234-249. 

7.  Manna,  Z. :  Mathematical  Theory  of  Computation.  McGraw  Hill, 
New  York,  1974. 

8.  Morris,  James  H.  Jr.  &  Wegbreit,  Ben:  Subgoal  induction. 

Com.  ACM  20,  4(April  1977),  pp.  209-222. 

9.  Petznick,  G.  W. :  "Introduction  to  combinatory  logic,"  in 
Brainerd,  W.  S.  &  Landweber,  L.  H. :  Theory  of  Computation, 
John  Wiley,  New  York,  1974. 

10.  Wijugarden,  A.  vam  (Ed.):  Report  on  the  algorithmic  lamguage 
ALGOL  68,  Nximerische  Math.  14,  79  ,  1969. 


Unclassified 


nCCulfITY  CV.*SSiriCATION  or  this  rAOC  r»h«i  OMaSinarMO 


REPORT  DOCUMENTATION  PAGE 


«.  title 

A  LAMBDA-CALCULUS  MODEL  FOR 
GENERATING  VERIFICATION  CONDITIONS 


READ  mSTRUCnONS 
BEFORE  COMPLETING  FORM 


>■  RECIPIENT'S  catalog  NUMRER 


S.  RECIMN 

^6^ 


>•  tyre  or  REPORT  S  PERIOD  COVERED 

Technical  Report 


PERroRMING  ORG.  REPORT  NUMRER 


■  AUTHORr*; 

S .  Keuaal  Abdali 
Franz  Winkler 


B.  PERroRMING  organization  NAME  AND  AOOREII 

Mathematical  Sciences  Department 
Rensselaer  Polytechnic  Institute 
Troy,  New  York  12181 


It.  CONTWOLLINO  OWWlCt  NAMC  ANO  AOORCSS 


ONTHACT  OR  ORANT  NUMRER^*} 


ONR  N00014-75-C-1026 


12.  RERORT  OATI 


■ 

I 


Office  of  Naval  Research  Resident  June  1981 

Representative  is.  numrer  or  pages 

715  Broadwav-5th  Floor,  N.Y..  N.Y.  10003  29 


.  MONITORING  AGENCY  NAME  A  AOORESSfll  <M«  ContralKnJ  Offler;  IB.  SECURITY  CLASS,  fe/ tlii*  rapan; 

Unclassified 


ASSiriCATION/ DOWNGRADING 
JULE 


IS.  distribution  STATEMENT  (el  Ihle  KeperlJ 


distribution  STATEMENT  A 

^Approved  fox  public  teleose) 
'Rv  Distribution  Unlimitod 

IT.  DISTRIBUTION  STATEMENT  (01  cn«  aeeireei  enteree  in  ,v,  U  MllereM  Ifem  Hepett) 


IS.  key  words  fCrnNmw  an  nvaraa  alWa  II  neeeeemy  and  IRanNiy  Sjr  Mack  maibar; 

Program  verification,  inductive  assertion,  verification 
condition,  lambda-calculus 


Unclassified 

•ECURITY  CLASSIPlCATieM  OP  THIS  PARE  ( 


DO  I  iSTn  1473  edition  op  I  NOV  st  is  obsolete 
SA«  0102.LP414-6601 


_ U; 

tlCUHITY  CtfcStllUCATlOW  OF  THIS  >»0C  flWi«n  Pf  ftitwO _ 

A  launbda-calculus-based  method  is  developed  for  the 
automatic  generation  of  verification  conditions.  A  pro¬ 
gramming  language  is  specified  in  which  inductive  assertions 
associated  with  a  program  are  incorporated  within  the  body 
of  the  program  by  means  of  assert  and  maintain-while  state¬ 
ments.  This  prograunming  language  includes  the  following 
features:  assignments,  conditionals,  loops,  compounds, 
ALGOL-type  block  structure.  A  model  is  developed  which 
consists  of  rules  to  translate  each  statement  in  this 
programming  language  into  the  lambda-calculus.  The  model 
is  such  that  the  launbda-expression  translation  of  any  program 
reduces  to  a  list  (tuple)  of  lambda-expression  representations 
of  all  verification  conditions  of  the  program.  A  proof  of 
this  property  is  given. 


Unclassified 

UCUfllTV  CLAtePICAtlON  OrTMIt  PAOtfMwi  DM*  ChMpmD 


